Skip to content

Resolve dynamic border and outline colors against the view trait collection in Fabric - #57837

Open
JacquesLeupin wants to merge 1 commit into
react:mainfrom
JacquesLeupin:fix/fabric-dynamic-border-color-trait-collection
Open

Resolve dynamic border and outline colors against the view trait collection in Fabric#57837
JacquesLeupin wants to merge 1 commit into
react:mainfrom
JacquesLeupin:fix/fabric-dynamic-border-color-trait-collection

Conversation

@JacquesLeupin

@JacquesLeupin JacquesLeupin commented Aug 5, 2026

Copy link
Copy Markdown

Summary

Fixes #57836.

On Fabric, borderColor and outlineColor set from a dynamic color (PlatformColor / DynamicColorIOS) are converted to CGColor without an explicit trait-collection resolve, so they resolve against UITraitCollection.currentTraitCollection — the system appearance. When the app's effective appearance differs from the system (Appearance.setColorScheme(...) / overrideUserInterfaceStyle), borders render the wrong variant, and views mounted while already attached under the override never get a traitCollectionDidChange: to heal them, so the wrong color persists. backgroundColor is unaffected because invalidateLayer already resolves it against self.traitCollection; Paper is unaffected because RCTView resolves border colors against the view's trait collection in displayLayer:.

This change applies the same treatment to the remaining color conversions in invalidateLayer:

  • the CoreAnimation border path (layer.borderColor),
  • RCTCreateRCTBorderColorsFromBorderColors (the border-image path), which now takes the view's trait collection,
  • both outlineColor paths.

Colors resolved with resolvedColorWithTraitCollection: are static, so the existing traitCollectionDidChange:invalidateLayer hook keeps them correct when the effective appearance changes. layer.shadowColor (in updateProps) shares the same latent flattening and could get the same treatment in a follow-up.

Changelog:

[IOS] [FIXED] - Fabric: resolve dynamic (PlatformColor/DynamicColorIOS) border and outline colors against the view's trait collection instead of the system appearance

Test Plan

Runnable single-file RNTester reproducer for the issue: main...JacquesLeupin:react-native:repro/fabric-border-trait-collection-57836 (edits only RNTesterPlayground.js). Equivalently, the reproducer from the linked issue as a stock npx @react-native-community/cli init app (New Architecture, iOS Simulator with system Light): one DynamicColorIOS({light: red, dark: green}) feeds a fill, a border on the border-image path, and a border on the CoreAnimation path; the app forces dark via Appearance.setColorScheme('dark'), then mounts a second set of boxes under the override.

  • Before: fills turn green, but the borders of views already mounted when the override flips stay red (the light variant) on both border code paths, permanently — the trait-change invalidation re-runs invalidateLayer, but the conversion reads the ambient trait state. Recycled views reattached under the override stick the same way (no trait change at all).
  • After (this change applied to the app's node_modules/react-native and rebuilt): every fill and border renders green, including the pre-override views once the trait-change invalidation runs against the view's own trait collection.

Also verified as a patch on a production 0.81.5 New-Architecture app that applies its theme via overrideUserInterfaceStyle at launch, where every PlatformColor border previously rendered the system variant: borders now follow the app theme across launch-time override, runtime toggles, and recycled list views; React-RCTFabric compiles with no new warnings.

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Aug 5, 2026
@facebook-github-tools facebook-github-tools Bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Aug 5, 2026
meta-codesync Bot pushed a commit that referenced this pull request Aug 21, 2026
…dii (#58028)

Summary:
Fixes #57841.

`outlineStyle: 'dotted'` and `'dashed'` render as solid on iOS. Android renders all three correctly, and the documented API lists all three values with no platform caveat.

### Root cause

`-[RCTViewComponentView invalidateLayer]` draws the outline through one of two paths:

- **Core Animation** — sets `_outlineLayer.borderWidth` / `.borderColor`. Cheap, but `CALayer` can only stroke a *solid* border.
- **Core Graphics** — `RCTAddContourEffectToLayer`, which forwards `outlineStyle` to `RCTGetBorderImage` and does honour dotted/dashed.

The branch choosing between them only looked at the border radii:

```objc
if (areBorderRadiiCircular(borderMetrics.borderRadii) && borderMetrics.borderRadii.topLeft.horizontal == 0) {
```

Every view **without a border radius** therefore took the Core Animation path, and its `outlineStyle` was silently dropped. Rounded views fell through to Core Graphics — which is why a dotted or dashed outline starts working as soon as a `borderRadius` is set.

The equivalent branch for *borders*, ~80 lines above, already gets this right: `useCoreAnimationBorderRendering` includes `borderMetrics.borderStyles.left == BorderStyle::Solid`, so a non-solid border falls through to Core Graphics. The outline branch never got the matching check when `outline` was implemented in #46444.

### Fix

Add the missing `outlineStyle == OutlineStyle::Solid` term, so non-solid outlines fall through to Core Graphics exactly as non-solid borders already do. Solid outlines keep the cheaper Core Animation path, so there is no cost for the common case.

### Why it went unnoticed

The only RNTester examples using `outlineStyle: 'dotted'` / `'dashed'` also set a `borderRadius`, so they only ever exercised the working path. This PR adds the square-cornered cases next to them, labelled, so all six combinations of `{square, rounded} × {solid, dashed, dotted}` are visible at once.

### Note on #57837

#57837 (open) rewrites the two `UIColor *outlineColor = ...` lines in this same block to resolve
dynamic colors against the trait collection. This change deliberately leaves those two lines
untouched — it only adds a term to the surrounding `if` — so the two patches touch disjoint lines
and should merge without conflict in either order.

## Changelog:

[IOS] [FIXED] - Render `outlineStyle: 'dotted'` and `'dashed'` on views without border radii

Pull Request resolved: #58028

Test Plan:
### Manual verification

RNTester → Components → View → Outline, iPhone 17 Pro Simulator (iOS 26.1), New Architecture, built from source (`RCT_USE_PREBUILT_RNCORE=0`).

| Before | After |
| --- | --- |
| <img src="https://raw.githubusercontent.com/neutronm/react-native/960889bd70d6cb18839f9d3586690908b0d8207d/assets/57841/before.png" width="420"> | <img src="https://raw.githubusercontent.com/neutronm/react-native/960889bd70d6cb18839f9d3586690908b0d8207d/assets/57841/after.png" width="420"> |
| `square dashed` and `square dotted` render solid | all six render correctly |

The rounded cases and every pre-existing example in the Outline screen are pixel-identical before and after; only the two square non-solid outlines change.

### Automated

| Command | Result |
| --- | --- |
| `yarn jest` | 222/223 suites, 5713 tests pass |
| `yarn flow-check` | `Found 0 errors` |
| `yarn lint` (`eslint --max-warnings 0 .`) | clean |
| `node ./scripts/clang-format.js <changed .mm files>` | no changes |
| `yarn build-types --validate` | `PASS  API snapshot is up to date.` |
| `tsc -p packages/react-native/__typetests__/tsconfig.json` | clean |
| `yarn test-ios` (`RNTesterUnitTests`) | `** TEST SUCCEEDED **` — 167 tests, 16 skipped, 0 failures |

The one Jest suite that did not pass in the full run (`GenerateComponentDescriptorH-test.js`) was a worker `SIGSEGV`, not an assertion failure; it passes 18/18 when run on its own.

### Unit tests

`React/Tests/Mounting/RCTViewComponentViewTests.mm` gains two cases next to the existing ones:

- `testSquareSolidOutlineUsesCoreAnimationBorder` — a square solid outline still uses `CALayer.borderWidth` (the fast path is not regressed).
- `testSquareDottedAndDashedOutlinesAreDrawnWithCoreGraphics` — square dotted and dashed outlines are drawn into `layer.contents` with `borderWidth == 0`.

`React/Tests/**` is excluded from the `React-Core` podspec, so these are not built by the OSS `RNTesterUnitTests` target. They were verified to compile against the installed pod headers with `clang -fsyntax-only -x objective-c++ -std=c++20`.

Reviewed By: cipolleschi

Differential Revision: D116779403

Pulled By: javache

fbshipit-source-id: b8d1f3508418016252ec9b1f9aaab7107c8f3b9f
@JacquesLeupin
JacquesLeupin force-pushed the fix/fabric-dynamic-border-color-trait-collection branch from 3f025de to 8ff2463 Compare August 21, 2026 19:19
@JacquesLeupin

Copy link
Copy Markdown
Author

Rebased onto current main after #58028 landed. The only conflict was the adjacent outline fast-path guard; the resolution preserves #58028’s OutlineStyle::Solid condition and this PR’s trait-collection color resolution in both outline paths.

The newly triggered Test All and Validate C++ API Snapshots runs are action_required with no jobs or logs, so they appear to be awaiting external-fork workflow approval rather than failing. Could someone with write access approve them when convenient?

The PR includes a runnable RNTester reproducer and before/after test plan. I also added a focused XCTest that forces ambient-light traits with a dark view trait collection and asserts that the direct border and outline layers resolve the dark color variant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.

Projects

None yet

1 participant